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AN ELECTRONIC BILL PAYMENT 
SYSTEM WITH ACCOUNT RANGING 

Crpss-Reference tp Related Applications 

This Application contains material related to the 
5 application entitled AN ELECTRONIC BILL PAYMENT SYSTEM WITH 

MERCHANT IDENTIFICATION (U.S. Application No. , filed ), 

and the application entitled AN ELECTRONIC BILL PAYMENT SYSTEM 

WITH ACCOUNT NUMBER SCHEMING (U.S. Application No. , filed 

) . These applications are filed simultaneously with the 

10 U.S. Patent & Trademark Office. 

Technical Field 

The present invention relates to electronic commerce. 
More particularly, the present invention relates to an 
electronic bill payment system with account ranging. 

15 BciqKground Art 

It has been common for many years for consumers to pay 
bills by way of a personal check written by the consumer to 
the order of an entity and delivered to that entity by mail or 
in person. With the proliferation of computers interconnected 

20 to computer networks, particularly the Internet, consumers can 

now pay bills electronically. However until recently it was 
not possible for a consumer, using a computer terminal, to 
interact with a single payment system capable of paying all 
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the consumer's bills whether by electronic means or by a paper 
check. Such a system now exists in the form of a consolidated 
bill payment system as described by Kight, et al. in U.S. 
Patent No . 5,383,113, entitled SYSTEM AND METHOD FOR 
5 ELECTRONICALLY PROVIDING CUSTOMER SERVICES INCLUDING PAYMENT 

OF BILLS, FINANCIAL ANALYSIS AND LOANS. 

Although the consolidated bill payment system described 
by Kight f et ah significantly advanced the state of the art, 
it did not focus on several problems which may arise in 
10 implementing a consolidated bill payment system capable of 

automatically paying consumer bills to merchants. One such 
problem is that consumers or data entry personal sometimes 
make mistakes in entering payment data required by the bill 
payment system. 

15 Such a case arises when a consumer's account number with 

a merchant is incorrectly entered . The payment system must 
submit a correct account number to the merchant who will use 
this account number to associate the payment with the 
consumer. Thus, a technique is needed to validate the 

20 submitted consumer's account number. 

A data entry person may also enter payment data which 
incorrectly specifies the merchant 1 s name or parts of the 
merchant's address. It has been found that merchant 
information such as the merchant name, address, zip code are 

2 5 typically mangled at the data entry stage . It has been 
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further observed that errors will often be made upon entry of 
the zip code. The merchant's name, address, and zip code is 
typically required by the payment system in order to, for 
example, retrieve merchant records from the merchant database. 
5 If this data is incorrect, the payment system may be unable to 

retrieve the correct merchant's record for processing a 
payment. Thus, a technique is needed to correctly identify a 
merchant record notwithstanding the submission of erroneous 
merchant data. 

10 A consolidated bill payment system must also have the 

capability to properly remit payments to the same merchant at 
more than one remittance center. Commonly a large commercial 
merchant, (e.g. , shoe company, Sears) will have several 
remittance centers distributed geographically so that 

15 customers can submit bills to a center within their location. 

Thus, a technique is required to ensure that consumer payments 
are remitted to the proper one of multiple remittance centers 
associated with the same. 

Advantageously, a consolidated payment system must also 

20 be able to handle the different processing formats and 

requirements of numerous separate merchant accounting systems. 
For example, each merchant's account system may require 
payment information, such as consumer account numbers, in a 
format different than that submitted by the consumer. For 

25 example, many merchant accounting systems will only accept an 
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account number with some portion of a consumer's last name or 
the consumer's zip code appended to the end of the account 
number presented by the customer. 

A merchant account system may even require an altered 
5 consumer account number which uniquely identifies the 

consumer. For example, two consumers, e.g., spouses, may have 
identical account numbers, but the merchant accounting system 
may designate the account of each consumer uniquely, such as 
by combining the account number with the prospective 

10 customer's name. Additionally, it is not unusual for a 

merchant to have different account numbers for a single 
customer. For example, an account number on an invoice which 
goes out electronically may be different from an account 
number for the same customer which goes out as a paper 

15 transaction. 

Thus, a consolidated bill payment system must be able to 
handle the various formats required by the merchant accounting 
system of each merchant. Accordingly, a technique is required 
to transform payment data received from the consumer into a 

20 form compatible with a merchant's accounting system. 



Objectives of the Invention 
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Accordingly, it is an object of the present invention to 
provide a bill payment system capable of receiving bill 
payment data on behalf of consumers via electronic means and 
automatically paying their bills to merchants. 
5 In particular, it is another object of the present 

invention to provide a technique for ensuring payments are 
remitted to the proper remittance center. 

It is a further object of the present invention to 
provide a bill payment system capable of handling incorrectly 
10 entered bill payment data received from consumers, and in 

particular to correctly identify a merchant record based on 
received information which may include erroneous data. 

It is still a further object of the present invention to 
provide a technique for furnishing payment information, 
15 including a payor 1 s account number with a merchant, in a 

format acceptable to a particular merchant accounting system. 

It is another object of the present invention to provide 
a technique for validating a consumer's account number with a 
merchant . 

20 Additional objects, advantages, novel features of the 

present invention will become apparent to those skilled in the 
art from this disclosure, including the following detailed 
description, as well as by practice of the invention. While 
the invention is described below with reference to preferred 

25 embodiment (s) , it should be understood that the invention is 
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not limited thereto. Those of ordinary skill in the art 
having access to the teachings herein will recognize 
additional implementations, modifications, and embodiments, as 
well as other fields of use, which are within the scope of the 
5 invention as disclosed and claimed herein and with respect to 

which the invention could be of significant utility. 

Summary Disclosure of the Invention 

In accordance with the present invention , a 
communications network couples a payor station, working on 

10 behalf of a consumer or corporate user, and a payee, typically 

a merchant, to a programmed computer, or possibly a 
distributed system of computers, which processes payment 
requests, allowing them to communicate and exchange data 
between themselves. The communications network may be of any 

15 type facilitating the flow of information among the entities, 

such as a private network or the Internet. To process payment 
requests, a first station, e.g. a payor station, transmits 
payment information , including name , address data , and a 
payor's account number with one of perhaps thousands of payees 

2 0 and a second station , e.g. a payment process ing server , 

receives this payment information and account number over the 
network. The first station initiates payment on behalf of 
consumers. The second station then processes the payment 
information by receiving a request to make a payment to a 
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payee having a plurality of payment remittance centers, the 
request including information identifying a payor account 
number with the payee, processes the account number to select 
a single remittance center of the plurality remittance centers 
5 to which payment is to be made, and then directs payment to 

the single remittance center. The correct remittance center 
is determined based on characteristics of the account number. 
These characteristics include any identifying information, 
such as any combination of digits or alphanumeric characters, 

10 such as, for example, alphanumeric characters identifying a 

payor's telephone number. 

In a further aspect of the present invention, the second 
station transforms the payor account number into an altered 
payor account number according to alteration rules. In a 

15 further aspect of the present invention, the second station 

processes the payment information to produce an eleven digit 
zip code for the payee, and accesses a database of payees, 
typically merchants, to locate a payee record corresponding to 
the eleven digit zip code. 

20 The first station collects payment requests from a 

plurality of consumers and feeds the requests to the second 
station . The f irst station and second station can be a 
computer or distributed network of computers. Typically, the 
second station is realized as a programmed general computer 

25 having a storage device and a processor. The storage device 
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is configured to store a database of payee records and also 
includes alteration rules and validation rules for each payee. 
As will be understood by those skilled in the art, the storage 
device may be configured in any one of many arrangements to 
5 store and manage databases, and could include a long term bulk 
storage configuration, such as one or more hard disks. 

The alteration rules can specify a wide variety of 
formats and may be realized as templates specifying fields or 
values, or as instructions for combining information from 

10 different fields. Typically, an altered account number is 

formed by combining the account number with some part of 
payment information or other information related to the payee. 
For example, the altered account number may include a portion 
of the payor's name, a portion of the payor's address, or a 

15 portion of the payor's zip code combined with the account 

number . 

According to another aspect of the present invention, 
validation rules for the account number are stored, and a 
determination is made as to whether the received account 
20 number conforms with the validation rules. The validation 

rules identify the expected general format for any payor 
account number associated with a payee. Validation rules are 
preferably realized as templates specifying fields or values, 
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but may take on other forms, and may even be algorithms. For 
example, a check digit algorithm could process the account 
number and compare the result to a check digit. 

Preferably, the general computer of the second station is 
5 a mainframe or mini computer or high powered workstation, but 

could be any other processing device capable of executing 
programmed instructions. Additionally, the general computer 
could be a distributed computer system in which various 
aspects of the system run on different platforms. The 

10 processor of the general computer is programmed to receive 

payment information and process the payment information to 
make a payment to a payee having a plurality of payment 
remittance centers, the request including information 
identifying a payor account number with the payee. The 

15 processor then processes the account number to select a single 
remittance center of the plurality remittance centers to which 
payment is to be made. Payment is then directed by the 
processor to the single remittance center. 

In a further aspect of the present invention, the 

20 processor verifies the account number conforms to the 
validation rules, and transforms the verified account number 
into an altered account number according to the alteration 
rules . 
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In a further aspect of the present invention, the 
processor receive payment information, processes the payment 
information, excluding zip code information, to produce an 
eleven digit zip code for the payee, access the database to 
5 locate a payee record corresponding to the eleven digit zip 

code, and then, preferably, makes an electronic payment to the 
payee after locating the payee record. 

The processor 1 s programed instructions can be stored on 
a storage medium. This article of manufacture may be 

10 portable, a floppy disk, a hard disk, a CD Rom, or other 

storage medium. The processor reads the programmed 
instructions from the medium and in accordance therewith 
receives a request from a payor to make payment to a payee 
having a plurality of payment remittance centers, the request 

15 including information identifying a payor account number with 

a payee, processes the account number to select a single 
payment remittance center of the plurality of payment 
remittance centers to which payment is to be made, and then 
generate a signal to direct payment to the single payment 

20 remittance center. 

In another aspect of the present invention, the processor 
may also read additional programmed instructions from the 
medium and in accordance therewith receives payment 
information including an account number for a payor, processes 

25 the payment information, excluding zip code information, to 
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produce an eleven digit zip code for the payee, and preferably 
accesses the database to locate a payee record corresponding 
to the eleven digit zip code, and then, preferably, makes an 
electronic payment to the payee after locating the payee 
5 record . 

In another aspect of the present invention, the processor 
may also read additional programmed instructions from the 
medium and in accordance therewith also verify the account 
number based upon validation rules for account numbers 
10 associated with one of a plurality of payees, and preferably 

transform the account number into an altered account number 
based upon alteration rules of the one payee, and transmit the 
altered account number to the payee. 

Brief Description of Drawings 
15 FIG. 1 is a system overview of a computerized bill 

payment system in accordance with the present invention. 

FIG. 2 is a diagrammatical representation of the 
remittance payment processor system of Figure 1. 

FIG. 3 is a flow chart illustrating merchant 
20 identification in accordance with the present invention. 

FIG. 4 is a block diagram illustrating how merchant 
identification accesses the merchant database. 

FIG. 5 is a flow chart illustrating account ranging in 
accordance with the present invention. 
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FIG. 6 is a flow chart illustrating account scheming in 
accordance with the present invention. 

Best Mode for Carrying out the Invention 

FIG.l generally depicts a bill payment system including 
5 consumers 8, merchants 4, a batch file processing system 7, a 

remittance payment processor (RPP) 3, merchant banks 5, and 
consumer banks 6. 

A consumer, including a corporate user, (payor) is the 
individual or other entity for whom payments are actually made 
10 and whose account will be debited by the amount of the 

payment. The consumers 8 typically submit their payments 
electronically to batch file processing system 7. The batch 
file processing system 7 represents any computer or network of 
computers capable of collecting payment requests from the 
15 consumers 8. 

Consumer banks 6 either physically or electronically 
holds money on account for consumers 8 . These accounts are 
debited by the amount of any payments made on behalf of the 
consumers 8. 

20 Merchants (payees) 4 are the persons or other entities to 

whom payments are made via the bill payment system on behalf 
of consumers. Merchants may include department stores, the 
phone company, the paper boy, a credit card company, as well 
as other persons and entities to whom payments are made by one 
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or more consumers 8. Merchants have accounts with merchant 
banks 5. 

The remittance payment processor (RPP) 3, as shown in 
Figure 2, includes a memory 16 storing programmed instructions 
5 for carrying out the functions of the RPP, a processor 17 for 
executing these instructions, and a merchant database 18 
storing information associated with the merchants. A batch 
file processing system 7 provides payment records collected 
from consumers 8 and transmits the batches of records to the 
10 RPP 3. 

A network 1 connects the above-stated entities making 
communications between them possible. The network may be of 
any type capable of facilitating the flow of information among 
the various entities. It could, for example, be a public 

15 telecommunication network, the Internet, or other type of 

communication network. The network 1 may also be physically 
realized as one or more networks. For example, in one 
possible embodiment, consumers 8 are coupled to batch file 
processing system 7 through one network and the batch file 

20 processing system is coupled to the remittance payment 

processor (RPP) through another separate network. 

In operation, consumers 8 make payment requests 
electronically and these payment requests are collected by the 
batch file processing system 7. The batch file processing 

25 system 7 then transfers the payment requests collected from 
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consumers 8 to the RPP 3 via the network 1. Payment 
information for a consumer will include several different 
types of information, such as the consumer account number, the 
merchant name, and address. 
5 FIG. 2 illustrates an overview of the process flow within 

the bill payment system of RPP 3. RPP 3 receives payment 
information from the batch file processing system 7, processes 
that payment information, and passes the processed information 
to a component 24 which then makes payments to merchants 4. 

10 A payment is implemented by crediting a merchant's account 

electronically with a bank or other financial institution, or 
transferring a check or draft to the merchant. A payment 
implementation also includes sending advice to the merchant. 
Advice is information on a bill payment presented to a 

15 merchant electronically in a form that the merchant's system 

can use to process the bill payment transaction and update the 
merchant's records. One possible mode of payment to a 
merchant is electronic funds transfer through the Federal 
Reserve Automated Clearing House (ACH) Network 26. Another 

20 electronic payment avenue is through the MasterCard RPS 

Network 30. Another remittance advice delivery mode is 
through Fax 22. Additionally, payment can also be made non- 
electronically to a merchant causing laser printer 28 to print 
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a check 32 or a draft 34. There is also a direct send 21 
capability whereby the payment system sends advice to a 
merchant 4 . 

RPP 3 stores or processes several different record types 
5 necessary to the bill payment process. A merchant record 

contains all necessary information needed to forward a 
payment. This includes a merchant name, address, and zip 
code. A consumer record include a consumer name, address, zip 
code, and consumer account number. A payment record will 

10 contain information related to payment, including payee 
identification, consumer identification, and the dollar amount 
of the transaction. The merchant records are stored in a 
merchant database 18. All other records as well as programmed 
instructions which direct the operation of the RPP are stored 

15 in a memory 16. The memory 16 could also store the merchant 

database 18 if desired. 

After receiving payment records from the batch file 
processing system 7, the RPP periodically initiates a payment 
cycle 20 which process the records to generate information 

20 which will be used to credit merchant accounts and form advice 

for merchant systems. The processing flow of the billing 
cycle contains, in addition to other processes, three 
particularly important processes necessary for successful 
processing of each payment record. These processes are 

25 merchant identification 19a, account ranging 19b, and account 
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scheming 19c, typically performed in this order. In the first 
step of processing a payment record, merchant identification 
attempts to identify a merchant in the merchant database 18 
based on information in the payment record. In the second 
5 step, the system will attempt to determine a remittance center 

of the merchant to which the billing information is sent. If 
a candidate remittance center is identified, the system enters 
the third stage of processing, account scheming. In account 
scheming, the system attempts to normalize a user account with 

10 a merchant according to the merchant's rules. If account 
scheming fails, the system will return to the account ranging 
process to attempt to identify another candidate remittance 
center, and from there, again into account scheming. 

Although the above described payment cycle is a 

15 preferable embodiment of the RPP, a payment cycle can include 

the three processes of merchant identification 19a, account 
ranging 19b, and 19c, in any order or combination. In 
addition, these three processes may be performed 
independently, and could also be performed and packaged 

20 individually outside the RPP. These three processes will now 

be described in further detailed herein referring to FIGS 3-6. 

FIG. 3 illustrates merchant identification. Using 
merchant identification, the RPP 3 is able to retrieve the 
correct merchant record from merchant database 18 based on a 

25 consumer's payment record submitted with possibly erroneous 
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merchant name and address information, e.g., street address, 
city, state, zip code. It has been observed that data entry 
operators will often make errors in the merchant's street 
address and zip code. The RPP 3 is capable of mapping the 
5 mangled merchant information supplied in the payment record 
into the proper merchant record in the merchant database 18 
notwithstanding the errors in the merchant information. 
Merchant identification as described herein, can be used in 
any implementation where merchant information is likely to 

10 contain errors and must be mapped into an existing merchant 

record in the merchant database. 

RPP 3 initiates merchant identification by step 60 which 
retrieves a payment record from one of the payment records 
previously submitted by the batch file processing system 7. 

15 The RPP will first attempt to retrieve a merchant record from 

the merchant database 18 by matching the merchant id included 
in the payment record against the records of the merchant 
database 18. If this is successful, the processing of the 
payment record can continue to the payment directions stage 

20 64. The payment directions stage is where the RPP determines 

where to send payments. This stage includes account ranging 
discussed below which determines the remittance center to 
which payment gets sent. If there is no match, the RPP 
continues to step 66. At step 66, the RPP maps the merchant's 

2 5 merchant name and address , excluding the provided street 
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address and zip code, into an eleven digit zip code. That is, 
the RPP produces an eleven digit zip code based on merchant 
name, city, and state in the payment information. In order to 
avail the merchant information which the inventors have 
5 determined to be mostly likely to contain errors, the received 

merchant street address and zip code are not considered. 
Hence, in step 66 the RPP 3 identifies an eleven digit zip 
code based only on the merchant's name, city, and state. 

Step 66 of merchant identification uses the indexing 

10 structure shown in Figure 4 to access one or more records from 

the merchant database 18. 

In step 66, the RPP 3 forms a 11 digit zip code index 82 
to associating the index entry with a merchant record in 
merchant database 18 via index 84. It may be possible that 

15 there is more than one merchant at a location identified by an 

eleven digit zip code. For example, there could be a 
remittance processing center on the floor of the building 
identified by the eleven digit zip code which handles payments 
for several merchants 4. In such a case, the RPP 

20 differentiates the correct merchant record from other possibly 

correct merchant records associated with the same eleven digit 
zip code by, after identifying merchant records indexed to the 
same eleven digit zip code, comparing some portion of the 
merchant's name, e.g., the first five characters with the 

25 characters of each merchant's name which has been combined 
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with the application zip code in the merchant index. The RPP 
3 is thereby able to uniquely identify the proper merchant 
record. 

If step 66 identifies a unique merchant record processing 
5 continues to step 64. However, if step 66 retrieves more than 

one merchant forming a group of records 86, then at step 67 
the RPP 3 will attempt to match one or more characters of the 
merchant's name 83 against the records 86 to identify a 
merchant record. If a match is found, processing continues to 

10 the payment directions stage 64. If there is no match, then 
the RPP will handle this contingency at step 68. If there is 
no merchant, the system may have provisions at step 68 for 
adding the merchant to the merchant database 18. 

FIG. 5 illustrates a payment direction stage, as 

15 performed in the preferred embodiment of the present 

invention, in which the RPP attempts to determine a remittance 
center to which payment is sent. The RPP determines a 
remittance center based on one or more of the following 
identification rules: 1) length of account number, 2) merchant 

20 zip code, 3) merchant name, and 4) account ranging. Each rule 

has in common that it identifies the remittance center based 
on some factor of the payment information. 

In Figure 5, the RPP 3 processes the payment record 
presented in step 51 to determine one of a plurality of 

25 remittance centers associated with the applicable merchant in 
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which to make payment. In step 53, the RPP chooses one of the 
above-mentioned four rules and at step 55 attempts to identify 
a remittance center. If a remittance center is found at step 
56, then the RPP directs payment to that remittance center 58. 
5 If the RPP is unsuccessful in determining a remittance center, 

the RPP cycles back to step 53 and picks a new rule for 
identification. By this process, the system cycles through 
all combinations of rules that identify remittance centers for 
the merchant. 

10 In account ranging, the correct remittance center is 

determined based on some characteristic of the consumer's 
account number. Typically a large merchant, such as credit 
card company will have multiple remittance centers to which 
respective consumer payments must be submitted. The payment 

15 record contains information which may be used to identify a 

remittance center besides an account number, such as an area 
code of the payor f s telephone number. A telephone phone 
utility might include each consumer's area code in the 
consumer's account number and require payments from all 

20 consumers within a particular area code be directed to a 
particular one of multiple remittance centers. A credit card 
company may require that payments from all consumers having 
the same first six digits in their account numbers be made to 
the same remittance center. 
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The payment direction process illustrated in Figure 5 is 
a preferred embodiment for determining payment direction. In 
this embodiment, the payment direction process includes 
account ranging as one of four possible methods of identifying 
5 a remittance center. However, in other embodiments, account 

ranging may be used in different combinations, or 
independently . 

FIG. 6 illustrates the steps for account scheming. In 
certain cases, the consumer account number received by the RPP 
10 as part of the payment information may contain errors. Hence, 

the RPP has no way of checking the account number against a 
previously stored account number associated with the 
applicable consumer to verify the accuracy of the received 
information. 

15 Using account scheming, the RPP receives, in step 12a, 

the consumer account number as part of the payment record. In 
step 42, the RPP checks to validate the account number. Then 
in step 46, the RPP alters the account number to correspond to 
a format required by a merchant's system 4 for processing. 

20 More particularly, the RPP validates and alters the 

consumer account number by storing separate business rules for 
each merchant which identify the expected general format for 
any consumer account number associated with that merchant. 
These business rules are stored as validation templates 40 in 

25 merchant database 18 for each merchant. The account number 
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received from the consumer is checked against the validation 
template to validate that the account number conforms to the 
general account number format to which an account number 
associated with the applicable merchant must conform. For 
5 example, the validation template for a merchant such as a 

credit card company may require an account number begin with 
the numbers "43" and be 18 digits long. Additionally, for 
some merchants the validation template will have check digit 
requirements. That is, the validation template can be used to 

10 confirm that the received consumer account number conforms to 
a check digit after being run through a specific algorithm. 

In operation, the RPP 3 performs, in accordance with 
programmed instructions stored on the memory 16, the 
validation procedure by comparing in step 42 the received 

15 consumer account number for the applicable merchant received 

in step 12a with the validation template, say 40, for that 
merchant to test the validity of the account number. If that 
account number is not valid, the payment directions are 
rejected as not valid in step 43 ; otherwise, the account 

20 number is considered valid. 

Once the account number has been validated, it is then 
modified in step 46 so as to conform to alteration rules 44 
for the applicable merchant. The alteration rules 44 are also 
stored in database 18. The alteration rules 44 relate to the 

25 format of the consumer ■ s account number in which the 
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applicable merchant system requires to process a consumer's 
payment. Typically, alteration rules would specify an altered 
account number which includes a portion of a payor's name with 
the account number, a portion of the payor's address with the 
5 account number, or a portion of the payor's zip code with the 
account number. Alteration by the RPP 3 involves notifying 
the received account number which will be furnished, along 
with payment, to the merchant. For instance, some merchant 
systems require that the consumer's account number always end 

10 in "120". Hence, in such a case, the RPP 3, in accordance 

with programmed instructions stored on the memory 16, modifies 
the received account number to append "120" to the end of the 
alpha-numeric sequence of the received account number. Once 
the account number has been modified so as to conform to the 

15 format required by the merchant system, the altered account 

number 47 is then transmitted from the RPP 3 to the merchant 
4 via the network 1, along with the payment, in step 48. 

It will also be recognized by those skilled in the art 
that, while the invention has been described above in terms of 

20 one or more preferred embodiments, it is not limited thereto. 

Various features and aspects of the above described invention 
may be used individually or jointly. Further, although the 
invention has been described in the context of its 
implementation in a particular environment and for particular 

25 purposes, e.g. a bill payment system, those skilled in the art 

IPDC:463.1 33500-00003 23 



Docket No,: 33500-00003 

will recognize that its usefulness is not limited thereto and 
that the present invention can be beneficially utilized in any 
number of environments and implementations. Accordingly, the 
claims set forth below should be construed in view of the full 
5 breadth and spirit of the invention as disclosed herein. 

The present invention is not to be limited in scope by 
the specific embodiments described herein. Indeed, various 
modifications of the present invention, in addition to those 
described herein, will be apparent to those of skill in the 
10 art from the foregoing description and accompanying drawings. 

Thus, such modifications are intended to fall within the scope 
of the appended claims. 
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CLAIMS 

1. A computer implemented remittance payment process, 
comprising the steps of: 

receiving a payor request to make a payment to a 
payee having a plurality of payment remittance centers, the 
5 request including information identifying a payor account 

number with the payee; 

processing the account number to select a single 
remittance center of the plurality remittance centers to which 
payment is to be made; and 
10 directing payment to the single remittance center. 

2 . The computer implemented remittance payment process 
of claim 1, wherein the account number is processed to 
identify information of the account number which corresponds 
to the single remittance center. 

3. The computer implemented remittance payment process 
of claim 2, wherein the identified information of the account 
number includes one or more alphanumeric characters 
identifying a single remittance center. 
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4. The computer implemented remittance payment process 
of claim 1, further comprising the steps of: 

providing a database including payee records; 

the request for payment further including payment 
5 information, such as payor's name and address data; 

processing the payment information to produce an 
eleven digit zip code for the payee; and 

accessing the database to locate any payee records 
corresponding to the eleven digit zip code. 

5. The computer implemented remittance payment process 
of claim 1, further comprising the steps of: 

storing in a database alteration rules for each 
payee indicating a format in which a payee expects to receive 
5 an account number; and 

transforming the account number into an altered 
account number according to the alteration rules. 

6. A remittance payment system, comprising: 

a communicative interface configured to receive a 
payor request to make payment to a payee having a plurality of 
payment remittance centers, the request including information 
5 identifying a payor account number with a payee; 



IPDC:463.1 33500-00003 



26 



Docket No*: 33500-00003 

a processor configured to process the account number 
to select a single payment remittance center of the plurality 
of payment remittance centers to which payment should be made, 
and to generate a signal directing payment to the single 
10 payment remittance center. 

7 . The remittance apparatus of claim 6 , wherein the 
processor is further configured to identify information of the 
account number which corresponds to the single payment 
remittance center and to select the single payment remittance 
5 center based upon the identified information. 

8. The computer implemented remittance payment process 
of claim 7, wherein the identified information of the account 
number includes one or more alphanumeric characters 
identifying a single remittance center. 

9. The remittance apparatus of claim 6, 

wherein the request for payment further includes 
payment information, such as payor's name and address data; 
and further comprising: 
5 providing a database including payee records; 
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a mapping unit processing the payment 
information to produce an eleven digit zip code for the payee; 
and 

a retrieval unit accessing the database to 
10 locate any payee records corresponding to the eleven digit zip 

code. 



10. The remittance apparatus of claim 6, further 
comprising: 

a verification unit to verify that the account 
number conforms to validation rules indicating expected values 
5 for fields of the account number; and 

a modification unit to alter the account number 
according to alteration rules expressing processing 
requirements of a payee to create an altered account number. 



11. An article of manufacture for processing payment 
inf ormat i on , compr i s ing : 

computer readable storage medium; and 
a computer program stored on the storage medium; 
5 wherein the stored computer program is configured to 

be readable from the computer readable storage medium by a 
computer and thereby cause the computer to: 
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receive a payor request to make payment to a payee 
having a plurality of payment remittance centers , the request 
10 including information identifying a payor account number with 

a payee; 

process the account number to select a single 
payment remittance center of the plurality of payment 
remittance centers to which payment is to be made; and 
15 generate a signal to direct payment to the single 

payment remittance center. 

12. The article of manufacture of claim 11, wherein the 
computer program is further configured to cause the computer 
to process the account number to identify information of the 
account number and to select the single remittance center 

5 based upon the identified information. 

13. The article of manufacture of claim 12, wherein the 
identified information of the account number includes one or 
more alphanumeric characters identifying a single remittance 
center . 

14. The article of manufacture of claim 11, wherein the 
computer program is further configured to cause the computer 
to: 
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receive a payor's payment information with the 
5 request for payment; 

process the payment information to produce an eleven 
digit zip code for the payee; and 

access a database of payee records to locate any 
payee records corresponding to the eleven digit zip code. 

15. The article of manufacture of claim 11, wherein the 
computer program is further configured to cause the computer 
to: 

receive the account number for the payor; and 
5 transform the account number into an altered account 

number according to alteration rules stored in a database for 
each payee indicating a format in which a payee expects to 
receive an account number. 



16. A system for processing payment information, 
comprising: 

a communications network; 

a first network station, coupled to the network, 
5 generating a payor 1 s payment information, including payee 
name, address data prepared by the payor, and an account 
number, and communicating the payment information and the 
account number to the network; and 
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a second network station, coupled to the network, 
10 receiving a payor's request for payment, the request including 

information identifying the payor 1 s account number with a 
payee , the payee having a plurality of remittance centers , 
processing the account number to identify a single remittance 
center of the plural remittance centers to which payment is to 
15 be sent, and directing payment to the single remittance 

center . 



17. The system for processing payment information of 
claim 16, wherein a characteristic identifying the single 
remittance center is located in the account number. 



18. The system for processing payment information of 
claim 17, wherein the characteristic of the account number 
includes one or more alphanumeric characters identifying a 
single remittance center. 



19. The system of claim 16, wherein: 

the second network station further processes the payment 
information to produce an eleven digit zip code for the payee, 
accesses a database of payees to locate any payee records 
5 corresponding to the eleven digit zip code. 
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20. The system of claim 16, wherein: 

the second network station further receives the payor's 
account number, stores in a database alteration rules for each 
payee indicating a format in which a payee expects to receive 
5 an account number, and transforms the account number into an 

altered account number according to the alteration rules. 
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ABSTRACT OF THE DISCLOSURE 

AN ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT RANGING 

In a computer implemented remittance payment process, a 
a payor request is received from a source to make a payment to 
a payee having many payment remittance centers. The request 
includes information identifying a payor account number with 
5 the payee. The account number is processed to select a single 

remittance center of the payor's many remittance centers to 
which payment is to be made. Payment is then directed to the 
single remittance center. 
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